Some companies that generate reports build a data warehouse containing user sensitive data and a plan of enforcing security on that data in a location outside the data warehouse. Typically, enforcing data security outside the data warehouse ties the customer to using that application anytime they want to grant users access to the data. Native security tools such as SQL*PLUS or Test ODBC will not enforce security, and with other applications the logic of separate MicroStrategy SQL engines or security filters would need to be identically replicated to ensure secure access.
Many companies choose not to implement security in the database but instead implement security in MicroStrategy™ using security filters. Security filters can control which parts of a data warehouse a particular user may view and/or access.
Reporting system and decision support system have been developed to efficiently retrieve selected information from data warehouses. One type of decision support system is known as an on-line analytical processing system (“OLAP”). In general, OLAP systems analyze the data from a number of different perspectives and support complex analyses against large input data sets. OLAP systems generate output upon execution of a report that includes a template to indicate the way to present the output and a filter to specify the conditions of data on which the report is to be processed.
Reports may be extremely complicated and require many seconds, minutes, and sometimes even hours to process. Designing such complex reports is labor intensive. Further, in current systems, once a report is designed, if a user desires to change the template, filter, or any other sub-object or component, a completely new report must be created through the same laborious tasks. Although some report writing wizards have been developed in this field, those wizards also must be programmed and often only provide specific options from which a report designer may choose. Accordingly, the report writing wizards are often not useful to the report designer that generates a complex report. The inflexibility of current report creation systems is a drawback of current OLAP.
One cumbersome task for report designers is creating different security filters for each user in order to restrict each user's access to database information. While it is desirable for a store manager to view information specific to the manager's store, it may be undesirable to allow a specific store manager to view performance information of other managers' stores. However, it may be desirable for a specific store manager to view aggregate store information and execute reports on an aggregate basis. In order to restrict specific access to data, prior art systems have required report designers to create a different security filter for each user. Thus, report designers would have to create and manage 300 different security filters if there were 300 different store managers. The security filter may enable all users to see aggregated data while enabling specific users to view only a subset of detailed data based on that user's security access.
A related problem is that the different security filters often fail to preserve confidentiality. Traditional systems typically require users to select one of the various security filters, e.g., by entering a user's name. By simply entering another user's name, one user may execute a report intended for another user and thereby view the other user's confidential information. From the perspective of the database, it has been impossible to determine the true identity of the user who is executing a report. Instead, the report would merely apply the filter according to the name provided by the user.
Other drawbacks with current systems exist as well.